fix: Await pending refresh before sending new requests - #142

Summary

Fixes #141 - New requests sent with stale token while refresh is in-flight.

• Add tokenWaitingRefresh getter to FreshMixin that awaits _refreshFuture without starting a new refresh
• Use it in onRequest (fresh_dio), send() (fresh_http), and request() (fresh_graphql) before reading the token
• Eliminates unnecessary 401/UNAUTHENTICATED responses for requests arriving during the refresh window

Problem

QueuedInterceptor (Dio) runs onRequest and onError on separate queues. While onError is awaiting a token refresh, new requests pass through onRequest with the old (already invalidated) token, causing unnecessary 401 round-trips. The same applies to fresh_http and fresh_graphql where send()/request() are fully concurrent.

PR #130 correctly prevents multiple parallel refreshToken calls, but does not prevent new requests from being dispatched with a stale token during the refresh window.

Solution

A single new getter in FreshMixin:

@protected
Future<T?> get tokenWaitingRefresh async {
  final pending = _refreshFuture;
  if (pending != null) {
    try {
      await pending;
    } catch (_) {}
  }
  return token;
}

It piggy-backs on the existing _refreshFuture from #130, no new dependencies, no changes to the refresh lifecycle.

This is kept as a separate getter from token intentionally: merging the waiting logic into token would risk deadlocks if performTokenRefresh implementations ever read token.

Changes

Test Coverage

Added 2 tests per package (fresh_dio, fresh_http, fresh_graphql) - 6 total:

Test Results

• fresh: 33 tests ✅
• fresh_dio: 46 tests ✅
• fresh_http: 43 tests ✅
• fresh_graphql: 31 tests ✅

All existing tests pass, no lint warnings.

Checklist

• Fixes New requests sent with stale token while refresh is in-flight #141
• No new dependencies
• Covers fresh_dio, fresh_http, and fresh_graphql
• Comprehensive test coverage with WITHOUT/WITH fix comparison
• All existing tests pass
• No lint warnings